références:: [[ISTQB_CTFL_Syllabus-v4.0_FR_1.0.pdf]]

ISTQB MOC

Mots clés

Conséquences d'un logiciel qui ne fonctionne pas
- perte de réputation
- perte d'argent
- blessures ou mort dans des cas extrêmes
Le but du test logiciel est d'évaluer la qualité des logiciel afin de limiter le risque de défaillances qu'ils pourraient avoir.
Le test de logiciel: activités qui permettent de découvrir les défauts et d'évaluer la qualité des artefacts logiciels.
Le test consiste en:
- la vérification, le contrôle de la conformité du système aux exigences spécifiées
- la validation, contrôle de la conformité du système au besoin des utilisateurs et des autres parties prenantes dans son environnement opérationnel.
Le test peut être:
- dynamique, implique l'exécution du logiciel
- statique, comprend l'analyse des revues et l'analyse statique

Évaluer les produits d'activités (exigences, User Stories, les conceptions et le code).
Provoquer des défaillances et trouver des défauts.
Assurer la couverture requise d'un objet de test.
Réduire le niveau de risque d'une qualité logicielle insuffisante.
Vérifier si les exigences spécifiques ont été satisfaites.
Vérifier qu'un objet de test est conforme aux exigences contractuelle, légales et réglementaires.
Fournir des informations au parties prenantes pour leur permettre de prendre des décisions éclairées.
Construire la confiance dans la qualité de l'objet de test.
Valider si l'objet de test est complet et fonctionne comme attendu par les parties prenantes.

Le test et le débogage sont deux activités distincte.
Les tests dynamiques peuvent déclencher des défaillances causées par des défauts dans le logiciel.
Les tests statiques permettent directement de constater directement des défauts dans l'objet de test.
Lorsque le test dynamique déclenche une défaillance, le débogage consiste à
- trouver les causes
- à analyser ces causes et les éliminer.
Le processus de débogage consiste dans le cas d'une défaillance trouvé par un test dynamique
- Reproduire la défaillance
- Diagnostique (trouver la cause racine)
- Correction de la cause
Un test de confirmation permet de vérifier si les correctifs apportés ont résolu le problème. De préférence, ce test doit être fait par la personne qui a découvert la défaillance.
Des tests de régressions peuvent permettre de vérifier si le correctif cause des défaillances dans d'autres parties du l'object testé.
Lorsque la défaillance a été trouvé par un test statique pas besoin de le reproduire ou de le diagnostiquer.

Le test aide à atteindre les objectifs convenus dans les limites de temps, du périmètre, de la qualité et du budget.
- En testant, en limite le temps passé à fixer des bugs en production
Les compétences de test sont utile à tous les parties prenantes du projet.

Le test est un moyen peu coûteux de détecter des défauts. Défauts qui seront ensuite éliminé par le débogage.
Le test fournis un moyen d'évaluer directement la qualité d'un objet de test à différents stades du cycle de développement.
Le test permet de prendre en compte les besoins utilisateurs même s'il ne sont pas inclus dans le cercle de développement.
Le test peut être requis pour répondre à des exigences légale ou contractuelles ou pour se conformer à des standards réglementation.

Test, forme de contrôle de la qualité
- approche corrective axée sur le produit
Assurance qualité est une approche préventive axée sur les processus, qui se concentre la mise en oeuvre et l'amélioration des processus.
- Par du principe que si on suit un bon processus, on aura un bon produit.

Les êtres humains peuvent faire des erreurs qui produisent des défauts qui peuvent à leur tour causé des défaillances.
Les erreurs peuvent provenir d'un manque de temps, de la complexité des produits, des processus, de la fatigue ou du manque de formation.
Un défaut peut ne pas causer de défaillances ou en causer que dans certaines conditions.
Des défaillances peuvent avoir d'autres sources que des erreurs. Elle peuvent être causer par des conditions environnementales, par exemple lorsque les radiations ou les champs électromagnétiques provoquent des défauts dans les microprogrammes.
cause racine

Le test permet de montrer la présence et non l'absence de défauts
- Le test ne peut pas prover qu'il n'y a pas de défaut
- Le test diminue seulement la probabilité d'en trouver
Le test exhaustif est impossible
- On ne peut pas tout tester
- Il est donc important de prioriser les cas de test et de tester en fonction du risque
Tester tôt permet d'économiser du temps et de l'argent.
- Les défauts qui seront résolu tôt dans le processus de test n'entraîne pas de défauts dans produit d'activités dérivés.
Regroupement des défauts
- Un petit nombre de composants contiennent souvent la plupart des défauts
- Principe de Pareto
Usure des tests
- Les mêmes tests sont de moins en moins efficace pour détecter de nouveaux
- Dans le cas des tests de régressions automatisé, la répétition des même tests est bénéfique.
Le test dépend du context
- Pas d'approche du test universelle
L'illusion de l'absence de défaut
- Ce n'est pas parce que le produit est testé à 100% que le produit sera un succès et mieux que les produits existants

Un processus de test se compose de plusieurs activités

La planification de test
- Définir les objectifs du test
- Sélectionner une approche pour arriver à remplir les objectifs
Pilotage et contrôle de tests
- Vérification continue de toutes les activités de test.
- Comparaison des progrès réels par rapport au plan.
- Contrôle de consiste à prendre des mesures nécessaires pour atteindre les objectifs du test.
Analyse de test
- Identifier les caractéristique testable
- Définir et prioriser
  - les conditions de test
  - les risques et les niveaux de risques
  - L'analyse de test répond à la "Que tester ?"
Conception des tests
Implémentation des tests
L'exécution des tests
Les activités de clôture du test

Connaissance en matière de test
Rigueur, attention, curiosité, souci du détail, méthode
Bonne communication, écoute active, esprit d'équipe
Réflexion analytique, esprit critique, créativité
Connaissances techniques
Connaissances du domaine
Les testeurs sont souvent porteurs de mauvaises nouvelles.
- Compétences en communication important

Faire tester le produit par une autre personne que le créateur permet d'être plus efficace dans la découverte de défauts.
Niveaux d'indépendances
- Auteur, aucune indépendance
- Personne de la même équipe, un peu d'indépendance
- Testeurs extérieur à l'équipe mais de la même organisation, indépendance élevé
- Testeurs extérieur à l'organisation, indépendance très élevé
Indépendance du test permet de tester et de trouver des défauts sans être influencer.
Trop d'indépendance peuvent conduire un isolement dans l'équipe de développement qui peuvent entraîner
- Problème de communication
- Manque de collaboration
- Relation d'opposition entre les développeurs et les testeurs
- Testeur indépendant peuvent considérés comme un goulot d'étranglement ou être tenus pour responsable des retards dans la release
  - Si c'est le cas, le problème peut venir d'une mauvaise évaluation du temps dédié au test et à la fixation des défauts dans la planification du projet.